(This PR is a bit large than the other one you opened, I'll take a look later)

Yeah, the PR is a bit too large for my taste too. :)

I didn’t mean for it to be merged as-is, more as a starting point for discussion around the issues I opened. Happy to split it up once we have a clearer idea of what we want to do for each one!

Could we mix authentication methods? E.g. a user having two authentication methods:

1. Caching_sha2_password with hash abcdefg
2. Auth_socket linked to username jdoe

This could be useful for migrating from one to another. Or when a authmethod has limitations (like auth_socket). Or it could be used for MFA

https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_multi_factor_authentication_methods.html

I’m not entirely sure, but I don’t think this is feasible. As discussed in #1069:

Playing a little more with this, I think the only way to allow for multiple passwords is actually to keep GetCredential as-is, but instead modify Credential so that it holds multiple passwords with a Passwords []string field.

My understanding of the MySQL protocol is that it's impossible to handle authentication against multiple auth plugins for a single user on the wire, even if the database implementation would support it.

For additional context: I previously tried to implement a server that stored credentials for both mysql_native_password and caching_sha2_password, with the goal of allowing any client to connect: older clients that only support mysql_native_password (and may lack newer auth capabilities), as well as newer clients that only support caching_sha2_password. I couldn’t make this work reliably.

From what I remember of these experiments, the only potentially viable strategy was for the server to announce mysql_native_password in the initial handshake and then request an auth switch to caching_sha2_password when needed, since the server speaks first in the MySQL handshake / authentication protocol. However, IIRC, when a client literally couldn't perform native password authentication (e.g. because it doesn’t have the plugin at all, such as the client installed with brew install mysql), the connection was failing before an AuthSwitchRequest could even be processed. The client couldn't be "rescued" by switching.

Given that, I’d prefer not to allow multiple authentication plugin names per user if we can’t guarantee that this will work end-to-end. Exposing this would likely be misleading for developers playing with go-mysql.

MFA is out-of-scope for me here.

@ramnes Yes, I agree with that.

Note that newer MySQL clients are able to do both native and caching_sha2. There was a macOS specific issue that broke that, but that was fixed: Homebrew/homebrew-core#201853

Newer MySQL versions did remove the server part of mysql_native_password and moved the client part to a loadable module (which is auto loaded).

Just double check even if you can't implement "a server that stored credentials for both mysql_native_password and caching_sha2_password", this PR is still needed? My only comment is #1072 (comment)

Yes, indeed! The original idea was to support multiple passwords per user, e.g. for API tokens, or rotating secrets.